Fix ValueOption optional args with ?param caller syntax#19742
Open
T-Gro wants to merge 1 commit into
Open
Conversation
Contributor
❗ Release notes required
|
When the SupportValueOptionsAsOptionalParameters language feature is enabled, do not force option<_> on caller-side ?name = expr arguments during overload inference. Leave the type as a fresh inference variable and let AdjustCalledArgTypeForOptionals (CalleeSide) reconcile against option<_> or voption<_>. Pre-LangVersion-10 behaviour is preserved. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
01ce17d to
a53024c
Compare
T-Gro
commented
May 18, 2026
Member
Author
T-Gro
left a comment
There was a problem hiding this comment.
Clean, well-scoped fix. The root cause was that TcMethodApplication_SplitSynArguments eagerly constrained the caller argument type to option<_> when the ?param = expr syntax was used, preventing ValueOption from ever unifying correctly.
The fix correctly gates on SupportValueOptionsAsOptionalParameters to leave the type as a fresh inference variable when the feature is enabled, letting later unification in AdjustCalledArgTypeForOptionals (CalleeSide branch) match the actual declared parameter type — whether option<_> or voption<_>.
Key points verified:
- Correctness: The CalleeSide branch at line 382 passes through
calledArgTyunchanged (which already handles both option/voption), so the deferred unification naturally resolves to the right wrapping type. - Backwards compat: LangVersion < 10 preserves old behavior (early
option<_>constraint). - Test coverage: Methods, constructors, both option variants, and langversion gating are all exercised.
- No inference regressions: Since
None/SomeandValueNone/ValueSomeare unambiguous on their own, removing the early constraint doesn't create inference ambiguity for practical cases.
LGTM ✅
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix caller-side
?name = exprsyntax for ValueOption optional parameters whenSupportValueOptionsAsOptionalParametersis enabled.Fixes #19711